The present application is not limited to Universal Mobile Telecommunications Systems (UMTS), and can be equally applied to Global System for Mobile communication/General Packet Radio Service networks (GSM/GPRS), or indeed any other telecommunication networks.
A typical architecture of a cellular radio system like the Universal Mobile Telecommunications System (UMTS) is shown in FIG. 1. The UMTS comprises mobile user equipment (UE), a radio access network (RAN) and one or more core networks (CNs). UMTS is a third generation radio system using wideband code division multiple access (W-CDMA) technology.
FIG. 2 shows a more detailed architecture of a radio access network comprising base stations and radio network/base station controllers (RNC/BSC). The base stations handle the actual communication across the radio interface, covering a specific geographical area also referred to as a cell. Besides controlling the base stations connected to it, the RNCs include functionality such as the allocation of radio resources, local mobility etc. An RNC connects:                to one or more core networks via the Iu interface,        to a number of base stations (node B's for the case of UTRAN) via the Iub interface and        possibly to one or more other RNCs via the Iur interface        
FIG. 3 provides an overview of the UE registration and connection principles within UMTS with a Circuit Switched (CS) service domain and a Packet Switched (PS) service domain. Further details for this can be found on the 3rd Generation Partnership Project (3GPP) website at http://www.3gpp.org/ in document “3GPP TS 33.102 Security Architecture”. User (temporary) identification, authentication and key agreement takes place independently in each service domain. User plane traffic is ciphered using the cipher key agreed for the corresponding service domain while control plane data is ciphered and integrity protected using the cipher and integrity keys from either one of the service domains.
The CS and PS domains individually and asynchronously establish a its security context with the peer sides of the UE. This security context can be considered, in its simplest form, to be established by running an Authentication procedure that generates the security keys associated and belonging to that Security Context. The Authentication procedure is optional and its execution is a decision of the network. The Authentication procedures, and the Security Context resulting from it, do not ensure security of the radio interface. To ensure security of the radio interface, it is required that the Security Setting procedure is executed. The Security Setting procedure ensures that any messages sent via the air interface are secure.
FIG. 4 provides a brief simplified illustration of the protocol sequence of events that happen for a normal Layer 3 request for service. The far left of FIG. 4 provides a view of the sequence of procedures that lead up to the setting of Integrity and thus ensuring the “over-the-air” (OTA) signalling messages are fully secured. Up until this security setting procedure is complete, and the integrity protection is activated, the OTA messages are not secure.
At step 1, the UE and the Service Radio Network Controller (SRNC) establish an RRC connection. This includes a transfer of limited security parameters at the RRC level and UE security capabilities. At step 2 the SRNC stores limited security parameters and UE security capabilities. At step 3, an “initial layer 3 (L3) message” with user identity, key sequence etc is sent to the visitor location register/serving GPRS support node (VLR/SGSN).
In return, at step 4, the VLR/SGSN forwards an authentication key generation to the UE. Step 4 is an optional step, which may or may not be run by the network. At step 5 a decision is made by the VLR/SGSN on the integrity and encryption required. At step 6, the VLR/SGSN requests the setting of security by sending a message to the SRNC. At step 7 the SRNC initiates the security procedures by sending a message to the UE. The security procedures are completed by the UE by sending a message back to SRNC at step 8. At step 9 the SRNC sends a further message back to the VLR/SGSN to complete the security settings. At step 10 the layer 3 services may proceed between the UE and the SGSN.
Further details can be found in 3GPP TS 24.008 Mobile radio interface Layer 3 specification; Core network protocols; Stage 3, and 3GPP TS 25.133 Radio Resource Control (RRC) protocol specification, both of which may be found at the 3rd Generation Partnership Project (3GPP) website at http://www.3gpp.org/.
In FIG. 4 it is highlighted that step 4, the Authentication procedure, is an optional procedure. The Network decides whether this should be run based on several parameters beyond the scope of this description. However, it should be noted that regardless of whether the Authentication is run by the network, the Security Setting procedure that turns on the integrity protection of the OTA (Over the Air) messages can still take place so long as a security context exist between the UE and the network.
FIG. 5 shows the protocol sequence of events for a Layer 3 request that is not accepted (and thus rejected) by the network. This reject sequence is the same regardless of whether the Layer 3 service requested is for establishing calls or sessions or for registering the UE to the network.
At step 1, the UE and the Service Radio Network Controller (SRNC) establish an RRC connection. This includes a transfer of limited security parameters at the RRC level and UE security capabilities. At step 2 the SRNC stores limited security parameters and UE security capabilities. At step 3, an “initial layer 3 (L3) message” with user identity, key sequence etc is sent to the visitor location register/serving GPRS support node (VLR/SGSN).
At step 4, the VLR/SGSN checks the validity of the layer 3 request. If the request is not acceptable, the VLR/SGSN rejects the request at step 5. This request rejection is sent over the network to the UE without integrity protection.
Based on the above-described system, it is possible for a hacker, or, in the words of Universal Mobile Telecommunications System (UMTS) lingo a “False Basestation”, to instigate service attacks against UEs by providing false information within non integrity-protected messages sent over the air interface to the mobile communication device. These attacks can cause a “Denial Of Service” (DoS) to the mobile user.
Incorporated within the UMTS, and GSM/GPRS before it, is a timer within the UE that inhibits subsequent automatic registration attempts to the PS domain following the abnormal failure of a registration procedure. This timer is designated in the system as timer T3302.
T3302 has a default value of 12 minutes, which is used from power on until a different value for the parameter is assigned. The UE can be assigned a different value for T3302 in the ATTACH_ACCEPT, ATTACH_REJECT, ROUTING_AREA_UPDATE_ACCEPT and ROUTING_AREA_UPDATE_REJECT messages.
The value assigned to T3302 is between 2 seconds and 3 hours 6 minutes. Alternatively, the T3302 parameter can be indicated as ‘deactivated’. The consequence of setting T3302 to ‘deactivated’ is that further registration attempts to the PS domain following the ‘abnormal failure’ of a registration procedure are disabled.
An ‘abnormal failure’ is defined as follows. When the network rejects the mobile NAS Layer 3 request, the network provides a reason in the system this is called the Reject Cause. This Reject Cause will inform the UE what next action the UE shall, should or may take. If a Reject Cause is not understood by a UE, the cause is termed an Abnormal Case and failures resulting from these are termed abnormal failures. Abnormal Cases also cover a) Lower Layer (ie. radio failures) b) Procedure timeout (ie. no response from CN) c) CN rejection for a reason that is not expected by the UE (for example, if a legacy UE is active in a later release of a network, for instance a CN of Release 98 sends a new Reject Cause #14 to a UE which is built to GSM Phase 2 Specifications).
If no further registration attempts are allowed, the UE is denied service until one of following actions occurs:
a) a manual request is triggered by the User (for example, a manual request for PS services), or b) the UE goes through a power cycle (that is, the user powers the unit down and then switches the unit back on), or c) there is a physical change of Routing Area (for example, the UE moves from one cell to another).
The UE uses the T3302 default value from power on and continues to use the default value until it is assigned a different value.
A further problem can exist for UEs that are already registered to the network. That is, an increase in the number of network registration attempts by individual UEs not yet registered can result in an increase in radio noise for those UEs already registered. Also, a loss of service may occur for the UEs already registered due to this increase in noise and/or a loss of bandwidth due to the large number of requests for registration.
The dangers of unprotected over-the-air (OTA) messages are known. Thus in addition to encryption protection, the UMTS has integrity protection designed into it. Further, the UMTS has stringent authentication rules and elaborate integrity and encryption algorithms and also checks to allow the mobile to verify the network is genuine. Examples of these security aspects can be found on the 3rd Generation Partnership Project (3GPP) website at http://www.3gpp.org/ in documents TS 33.102 and 24.008.
In order to secure OTA messages in UMTS the integrity protection must be executed. The integrity protection starts after the Authentication and Key Agreement (AKA) procedure is optionally run. Although it is not necessary to run the AKA every time the UE accesses the network, the integrity protection must be started at the earliest possible opportunity every time the UE accesses the network. Security aspects in UMTS can therefore only be applied once the network and the UE run the integrity protection, and thus make OTA messages secure.
In UMTS integrity protection is triggered by the Core Network (CN) once the CN has received and processed the very first NAS (Non-Access Stratum) Layer 3 message and finds the NAS layer 3 request to be acceptable the CN proceeds further with that NAS Layer 3 request. If the CN finds the UE's first NAS Layer 3 request message unacceptable the CN rejects the UE by sending a reject message in the form of either an ATTACH_REJECT or ROUTING_AREA_UPDATE_REJECT message. The security procedure that triggers integrity protection of OTA messages is not started, because it is thought that, if the CN is rejecting a service request, enabling security is unnecessary as the UE-network transaction is expected to be terminated. This means that OTA reject messages to the mobile that are not Integrity protected are unsecured.
Further, it is possible for the T3302 timer parameter in the reject messages ATTACH_REJECT and ROUTING_AREA_UPDATE_REJECT to be manipulated in order to instigate a Denial of Service attack against the UE. This could be possible by intercepting the reject messages from the network and subsequently corrupting the T3302 timer parameters. However, it is more likely that a potential hacker would construct an entirely false reject message (ATTACH_REJECT or a ROUTING_AREA_UPDATE_REJECT) and send it to the UE.
Therefore, a hacker can instigate a Denial of Service attack against any UMTS mobile by manipulating parameters in the ATTACH_REJECT or ROUTING_AREA_UPDATE_REJECT messages that are not Integrity protected.
In the worst case, as explained above, this Denial of Service attack can lock mobiles out of PS services until the UE physically moves, the user triggers a specific request for PS services or the user carries out a power reset.
In GSM/GPRS and UMTS up to Release 5, the system has been designed with a process loop whereby a registration procedure attempt that fails abnormally will be repeated. Registration repeats are controlled by timers (other than T3302) and the movement of the UE within the Network. A UE shall attempt the registration procedure 5 times before T3302 is started.
Therefore, up to UMTS Release-5 there is statistically more than a good chance that any Registration Reject and its information, if corrupted by a hacker, will be updated by the next genuine Registration Reject or made irrelevant by a successful registration or registration update. However, the network does not necessarily refresh any corrupted parameters in T3302, as it is optional for the network to provide a parameter for T3302. Furthermore, a network cannot determine if a hacker has previously provided a corrupt value for T3302. So a corrupted T3302 that is not updated will be applied when the repetition of the registration procedure comes to an end. Also, the corrupted T3302 will be used the next time the mobile gets to a situation where T3302 has to be started again.
One problem with this existing solution is that, given that each occurrence of an abnormal condition counts as a failure to a registration procedure attempt, a hacker can, by ‘forcing’ 5 successive occurrences of abnormal failures, bring an end to the entire registration procedure process loop and so cause T3302 to be started.
The above-described problem is exacerbated by a change to Release 6 of the NAS specification by the introduction of a means to by-pass the existing solution. In UMTS Release 6, the same implicit solution of repeating the registration procedure 5 times exists prior to starting timer T3302. So there is an equally good chance of a genuine network updating a corrupted T3302 parameter. However, similar to Pre-Release 6, there is no guarantee that the network will update T3302 and the network does not know a hacker has corrupted T3302.
Also, changes to Release 6 of the NAS specification allow the repeating registration procedure loop to immediately end if certain Reject Causes are received by the UE. The changes to Release 6 can be found in Tdoc N1-041602 at the 3GPP website indicated above.
Therefore, a hacker can not only corrupt the system value of T3302 but also provide a Reject Cause that forces the mobile to stop further automatic registration attempts until the corrupted T3302 is changed.